What

Add .github/workflows/claude-review.yml as a reusable workflow that runs anthropics/claude-code-action to review pull requests. Callers should trigger on pull_request (recommended for safety); pull_request_target is supported but only for repos that strictly require reviewing fork-based contributions. The workflow accepts an optional prompt input (with a sensible default) and a required anthropic_api_key secret.

Why

Four stellar repos (rs-stellar-strkey, rs-soroban-sdk, stellar-cli, stellar-core) each maintain their own copy of the claude-review workflow. The stellar-core copy diverged with the more secure pull_request_target flow needed for fork PRs from org members. Centralizing here lets all repos share one hardened implementation and keeps the security model in one place, so future updates land in a single file instead of being copied across repos.

Example

Caller workflow:

name: Claude Review
on:
  pull_request:
    types: [ready_for_review, synchronize]

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

permissions: {}

jobs:
  review:
    uses: stellar/actions/.github/workflows/claude-review.yml@main
    secrets:
      anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

To override the default prompt:

jobs:
  review:
    uses: stellar/actions/.github/workflows/claude-review.yml@main
    with:
      prompt: |
        REPO: ${{ github.repository }}
        PR NUMBER: ${{ github.event.pull_request.number }}
        The PR's checked-out files are in the `pr-head/` subdirectory.
        ...custom instructions...
    secrets:
      anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Security model

The reusable workflow supports both pull_request (recommended) and pull_request_target (use only for repos requiring fork-based contributions):

• With pull_request, fork PRs cannot be reviewed (GitHub strips secrets on this event); only same-repo PRs work. This is the safer default.
• With pull_request_target, fork PRs from org MEMBERs or the repo OWNER are reviewable because secrets are available and the workflow runs from the trusted base branch. This is the more dangerous "pwn request" trigger; the workflow's mitigations (author-association gate, pr-head/ isolation, minimal permissions) exist specifically to make this mode safe to use.
• An if: gate restricts execution to non-draft PRs that are same-repo or authored by MEMBER/OWNER. In pull_request_target mode this is a security boundary; in pull_request mode it just filters which PRs are reviewed.
• Trusted base ref is checked out at the workspace root (for pull_request_target); the PR head is checked out into isolated pr-head/, exposed to Claude via --add-dir pr-head. Repo-local config in the PR head (.git/config, .git/hooks, .npmrc, etc.) is not picked up by tools running at the workspace root.
• Workflow-level permissions: {} and minimal job-level permissions (contents: read, pull-requests: write, id-token: write).
• fetch-depth: 0 on both checkouts so the agent can use git log / git blame.

The full threat model and rationale are documented inline in the workflow's security note.

Upstream Changes in Support

• Use shared claude-review reusable workflow stellar-core#5270
• Use shared claude-review reusable workflow stellar-cli#2580
• Use shared claude-review reusable workflow rs-stellar-strkey#120
• Use shared claude-review reusable workflow rs-soroban-sdk#1874